I like this idea for sure!
In this case won't the Mailer need to be configured or it will throw errors?

How about supporting a null Mailer instead so by default it doesn't proxy but it can be configured to proxy.
Note btw that all instanceof checks that you might do in user code will still fail.

I like this idea for sure! In this case won't the Mailer need to be configured or it will throw errors?

No, there is default configuration for mailer defined for this case, and it should be compatible with current codeception modules mailer

How about supporting a null Mailer instead so by default it doesn't proxy but it can be configured to proxy.

I do not see why would we want to over complicate it when current implementation just acts as inferior version of symphony mailer

Note btw that all instanceof checks that you might do in user code will still fail.

Nothing that can be done unfortunately

edit://
other way to do it would involve mocking....

No, there is default configuration for mailer defined for this case, and it should be compatible with current codeception modules mailer

You just set it to the default mailer class right? But that will throw exceptions: https://github.com/yiisoft/yii2-symfonymailer/blob/master/src/Mailer.php#L76

    private function getTransport(): TransportInterface
    {
        /** @psalm-suppress RedundantPropertyInitializationCheck Yii2 configuration flow does not guarantee full initialisation */
        if (!isset($this->_transport)) {
            throw new InvalidConfigException('No transport was configured.');
        }
        return $this->_transport;
    }

I think in the default config you supply you should configure the transport (Symfony includes a NullTransport that you can use). If you don't do it your fix will break stuff for others.

(This is what I think based on reading the code; you may argue this point if you know it works differently)

Nothing that can be done unfortunately

I was thinking the new lazy proxies (in php8.4) might be of use here; but I don't think you can actually intercept calls.

other way to do it would involve mocking....

Nah that's definitely overly complicated.

LGTM; some basics that tests / phpstan are pointing out.

If you can please add return types as well. This lib requires php >= 8.0 meaning we can add things like :void return type even if the base classes in Yii don't have them. -- i will not block merging for this, so it's up to you.

LGTM; some basics that tests / phpstan are pointing out.

If you can please add return types as well. This lib requires php >= 8.0 meaning we can add things like :void return type even if the base classes in Yii don't have them. -- i will not block merging for this, so it's up to you.

I'm going to just add basic docker-compose in order to run tests(as I work exclusively in containers nowadays in order to not think about what version of PHP or other dependencies some particular project needs), if that is fine with this project

I´ve just came into the issue mentioned here a few days ago and the solution i used is very simple. Using container definitions you can easiliy override TestMailer and with a simple and harmless code implementation in your mailer you can make it complete compatible with codeception yii2 module: yiisoft/yii2#14718

It's not a clean solution though... If internal structure of codeception changes your tests will break.

I'm sorry but these last changes add all kinds of implementation specific knowledge. I don't see why codeception needs to know about swiftmailer or symfony mailer...

I realize I contradict my earlier statement, I did not realize we'd have to add an additional dependency.